home *** CD-ROM | disk | FTP | other *** search
/ World of Video / World of Video.iso / datafiles / gfx_formats / gif / gftlzw.txt < prev    next >
Text File  |  1995-02-13  |  7KB  |  152 lines
  1.     Printing Gif Pictures from Macintosh to LaserWriter - John Jeppson
  2.  
  3. Gif Developers with DL17 access have my permission to use this material in
  4. their own programs.
  5.  
  6. \ Last Revision: 11/21/87  10:30:32 PM  JRJ
  7.     - discusses necessity, during _OpenPicture, of breaking up the
  8.       PostScript program/image into a series of 32K chunks in sequential
  9.       PicComments.
  10.  
  11.  
  12. This file describes one technique for printing Gif images on the LaserWriter 
  13. using up to 256 gray tones.  This version prints the picture centered on an 
  14. 8.5 x 11 inch page.  The picture is rotated if necessary.  
  15.  
  16. The overall strategy is to create and transmit to the LaserWriter the 
  17. following PostScript program.  The program is an ascii text file.  Lines 
  18. of text should be separated by a newline character (ascii 13).  
  19.  
  20. POSTSCRIPT PROGRAM:
  21.  
  22.     gsave initmatrix                        % leave out these comments
  23.     /width   paramW def                     % we supply 4 parameters
  24.     /height  paramH def                     % usually width = xPix
  25.     /xPix    paramX def                     %   and  height = yPix
  26.     /yPix    paramY def
  27.     /-yPix   yPix neg def
  28.     /inches  {72 mul} def
  29.     /centerPicture                          % procedure definition
  30.       {4.25 inches 5.5 inches translate     % center the coord.system
  31.       width 6.5 inches gt  {90 rotate} if   % rotate if width > 6.5 inches
  32.       width 2 div neg  height 2 div neg     % lower left corner of picture
  33.       translate} def
  34.     /scalePicture
  35.       {width height scale} def
  36.     /picstr                                 % temporary string variable
  37.       xPix 256 le                           %   length = xPix 
  38.       {xPix} {256} ifelse                   %   or maximum 256
  39.       string def
  40.     /pixImage                               % actually reads image data
  41.       {xPix yPix 8 [xPix 0 0 -yPix 0 yPix]  % "transform matrix" 
  42.       {currentfile picstr readhexstring pop}
  43.       image} def
  44.     centerPicture                           % do these procedures now
  45.     scalePicture
  46.     pixImage                                % read the image
  47.   <*** actual image data goes here ***>
  48.     showpage grestore                       % print and clean up
  49.     
  50.  
  51. The image data must follow immediately after the ascii word "pixImage", 
  52. separated by a single carriage return.  The image data is a stream of ascii 
  53. hexadecimal characters.  Characters not in ['0'..'9','A'..'F','a'..'f'] are 
  54. ignored.  Each PAIR of characters represents one 8-bit pixel value.  Thus the 
  55. image is coded as a single hex string consisting of exactly (xPix * yPix * 2) 
  56. hexadecimal characters.  
  57.  
  58. "pixImage" will be invoked repeatedly, each time reading length(pixstr) 
  59. pixels into pixstr, and thereby consumming twice that many hexstring
  60. characters from the image data.  On the last read it is possible that
  61. only a few pixels will remain.  Nevertheless the "readhexstring" operator
  62. will read 2*length(pixstr) characters from the incoming data stream, entirely
  63. filling pixstr each time. It is essential to end this read with the PostScript
  64. file mark just past the image data so that the following commands 
  65. "showpage grestore" will be correctly interpreted. Therefore it may be
  66. necessary to pad the image data with extra hexadecimal characters in order
  67. to come out even.  That occurs in this particular program when:
  68.  
  69.         xPix > 256          ; narrower pictures are read by full rows
  70.  
  71.             AND
  72.  
  73.         extra pixels > 0
  74.  
  75.   where
  76.  
  77.         extra pixels = total.pixels MOD 256
  78.  
  79. Remember to add TWO extra hexadecimal characters for each "extra" pixel.  
  80. This requirement stems from limiting the length of pixstr to 256, which is 
  81. NOT required by PostScript. The LaserWriter, however, has only marginal
  82. amount of memory for its task.
  83.  
  84. The four parameters: width, height, xPix, and yPix  must be supplied as
  85. ascii text strings substituted for the characters: "paramW", "paramH",
  86. "paramX", and "paramY", respectively.  I simply move the PostScript text
  87. into a handle, convert ScreenWidth (etc.) into ascii text, and replace
  88. the characters "paramW" using _Munger.  Best to do this before adding
  89. the image data so that Munger doesn't have to move so many bytes each time.
  90.  
  91. Don't forget to add the final commands: "showpage grestore" after the
  92. image data.
  93.  
  94.  
  95. TRANSMITTING TO LASERWRITER:
  96.  
  97. I'm using the easy (but memory intensive) method of creating a QuickDraw 
  98. picture and including the entire text (PostScript program + image data) in a 
  99. Picture Comment.  It is probably possible save large amounts of memory by 
  100. sending the stuff via direct calls to AppleTalk or via "Low Printing" 
  101. commands as found on page 26 of LaserWriter Manual.  I haven't yet tried
  102. those methods.
  103.  
  104. The Picture Comment technique is outlined on page 48 of LaserWriter Manual.
  105.  
  106. Since most pictures exceed 32K in size it is necessary to use a version-2 
  107. picture.  This is made automatically when _OpenPicture is called while the 
  108. port is set to a color window.  It is not necessary to use the new trap 
  109. _OpenCPicture since we are not actually drawing color stuff in the Picture.  
  110. In fact we don't draw anything, we just include PicComments.  
  111.  
  112. Unfortunately, even in version-2 pictures the PicComment can handle only 32K 
  113. bytes at a time.  It is therefore necessary to break up the completed 
  114. PostScriptProgam+image into a sequence of smaller handles each less than 32K 
  115. in size. These separate pieces are simply incorporated into a series of
  116. PicComments sent one after another in the correct order. 
  117.  
  118. thePicture := OpenPicture(theWorld);
  119.     (* DO THIS WITH A COLOR WINDOW CURRENT *)
  120.     ClipRect(theWorld);           (* I'm using:  0 0 1000 1000 *)
  121.     PicComment(PostScriptBegin,0,nil);
  122.     <for each piece of the PostSciptProgram>
  123.         begin
  124.             PicComment(PostScriptHandle,length(thisPiece),thisPieceHandle);
  125.         end
  126.     PicComment(PostScriptEnd,0,nil);
  127. ClosePicture;
  128.  
  129. Then I send it from a Hi-Printing loop
  130.  
  131. (in Forth)  
  132.     : uploadText
  133.         printing.prep                           \ essentially _PrOpen
  134.         open.document                           \ _PrOpenDoc
  135.         open.page                               \ _PrOpenPage
  136.             thePicture theWorld draw.picture    \ _DrawPicture
  137.         close.page                              \ _PrClosePage
  138.         close.document                          \ _PrCloseDoc
  139.         printing.done ;                         \ _PrClose
  140.  
  141.  
  142. NOTE:
  143.     The PostScipt program expects 8-bit "pixels" in the image data as
  144. directed by the "8" parameter in
  145.  
  146.       {xPix yPix 8 [xPix 0 0 -yPix 0 yPix]  % "transform matrix" 
  147.  
  148. If you have only 16 or so graytones you can pack the image data (left to 
  149. right) and change the number of bits in the transform matrix. You would
  150. then have to adjust the size of "picstr" and the padding procedures to
  151. make things come out even. Doesn't seem worth the trouble.
  152.